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TRANSMISSION METHOD, TRANSMISSION 
SYSTEM AND TERMINAL UNIT 

TECHNICAL FIELD 

[0001] The present invention relates to transmitting application software to 
terminal units. 

BACKGROUND ART 

[0002] Mobile units equipped with a function of executing Java-AP (Java 
Application) software by carrying out a program written in accordance with Java 
(trademark registered) programming language, and downloaded via a network are 
in widespread use. 

[0003] Java-AP software includes a Jar (Java Archive) file and an ADF 
(Application Descriptor File). The Jar file contains a program, which provides a 
user with certain Java-AP. The ADF is dependent upon the Jar file, and contains, 
for example, URL showing where a Jar file is stored (hereinafter, referred to as 
package URL), the size of a Jar file, the most recent date when a Jar file is 
changed and other necessary information. 

[0004] A mobile unit downloads the relevant software to the desired Java-AP 
by following the process described below. First, the mobile unit obtains an ADF 
pertaining to the desired Java-AP from a server unit, which constitutes WWW 
(World Wide Web). 

[0005] The mobile unit, which obtains an ADF checks the content of the ADF 
and the available volume of the memory installed in the mobile unit to determine 
whether the Jar file pertaining to the desired Java-AP can be installed in the 
mobile unit. When the mobile unit determines that Java-AP software can be 
installed, the mobile unit obtains from a server unit constituting WWW a Jar file, 
which contains the Java-AP software, by using package URL contained in the 
ADF. Hence, the process of downloading Java-AP software is complete when the 
Jar file is obtained. Hereinafter, in the mobile unit, installation of the downloaded 



Java-AP software is carried out, and the Java-AP software can be activated when 
required. 

[0006] Incidentally, when the Java-AP software is installed in a mobile unit 
the activation of Java-AP is subject to greater restriction than the activation of 
functions that are native to the mobile unit, such as a communication application 
function. The activation of Java-AP is restricted in that it is unable to access 
confidential data contained in a mobile unit, such as telephone numbers for 
example. By imposing strict restrictions in this manner, leakage or falsification of 
confidential data contained in a mobile unit occurring due to malfunctioning Java- 
AP or caused intentionally, can be prevented. 

[0007] However, imposing the above-mentioned restriction on all Java-AP 
uniformly does not adequately meet the needs of a user of a mobile unit or an IP 
(information provider). For example, some users seem to feel that Java-AP could 
be allowed to refer to some of the private information stored in a mobile unit as 
long as security is guaranteed. Also, some IPs wish to provide more useful Java- 
AP, which uses some of the private information stored in a mobile unit, or some of 
the functions a mobile unit is equipped with. 

[0008] To fulfill these requirements, a system in which a trustworthy 
organization such as a communication provider providing a communication 
service to users of mobile units, is entrusted with the responsibility of authorizing 
Java-AP to operate with greater flexibility. The trustworthy organization notifies 
the operational rules to mobile units using Java-AP, and the mobile units can 
restrict the operation of Java-AP on the basis of the prescribed rules. In this 
system, only a trustworthy organization should be entrusted to administer the 
authorization of a more flexible operation of Java-AP. 

[0009] When the above-mentioned system is applied to the downloading 
process of Java-AP software, information showing the authorization in an ADF or 
a Jar file must be included by a trustworthy organization. Since a Jar file is 
updated by an IP as required, it is appropriate for an IP to own a Jar file. 
However, if an IP owns a Jar file, the organization entrusted to authorize the 
operation of Java-AP cannot at the same time own the Jar file. Hence, it is 



preferable for the trustworthy organization to own an ADF rather than the Jar file, 
and the ADF should contain data showing authorization. 

[0010] However, since the content of an ADF is dependent upon a Jar file, an 
ADF owned by a trustworthy organization needs to be updated once an IP updates 
a Jar file. At this stage, the ADF is updated by cooperation between the 
trustworthy organization and an IP since the trustworthy organization needs to 
administer the ADF so as to exclude the involvement of other companies. The 
drawback in this procedure is that the operation becomes busy. Also, updating an 
ADF becomes necessary at times even without the updating of a Jar file when, for 
example, access to a certain Jar file gets flooded, and the Jar file is moved to 
another server unit in the IP. In this instance, since the location where the Jar file 
is stored is changed, a package URL contained in the ADF needs to be changed. 
However, since the ADF is administered by the trustworthy organization and 
excludes the involvement of other agents, the updating operation of an ADF could 
become a very busy one. 

DISCLOSURE OF INVENTION 

[0011] The present invention was developed to overcome the stated problems 
of the conventional art, and its object is to provide to a terminal unit, which 
permits operation in accordance with authorization; a system to enable 
transmission of software for achieving the application by transmitting a plurality 
of files dependent upon each other. 

[0012] The present invention provides a transmission method comprising: a 
process for a transmission system comprising an information providing server unit 
storing an entity file containing software for achieving an application; an 
administering server unit storing a security descriptive file containing 
authorization information showing authorization given to an application achieved 
when a terminal unit executes the software; and another information providing 
server storing an application descriptive file having contents dependent upon the 
entity file, into which a storage location of the entity file and a storage location of 
the security descriptive file are written; a process for transmitting an application 



descriptive file to a terminal unit when a storage location of the application 
descriptive file is notified by the terminal unit; a process for the terminal unit to 
notify to the transmission system a storage location of the security descriptive file 
contained in the application descriptive file transmitted from the transmission 
system; a process for the transmission system to transmit to the terminal unit the 
security descriptive file with security assured on the basis of the storage location 
of the notified security descriptive file; a process for the terminal unit to notify to 
the transmission system the storage location of an entity file contained in the 
application descriptive file transmitted from the transmission system; and a 
process for the transmission system to transmit to the terminal unit the entity file 
on the basis of the storage location of the notified entity file. 
[0013] In the above-mentioned method, the transmission system, when a 
storage location of an application descriptive file is notified by the terminal unit, 
transmits the application descriptive file to the terminal unit; the terminal unit 
notifies to the transmission system the storage location of the security descriptive 
file contained in the obtained application descriptive file; the transmission system, 
on the basis of the storage location of the notified security descriptive file, 
transmits to a terminal unit the security descriptive file with security assured; the 
terminal unit notifies to the transmission system the storage location of the entity 
file contained in the application descriptive file transmitted from the transmission 
system; and the transmission system, on the basis of the storage location of the 
notified entity file, transmits to the terminal unit the entity file. 
[0014] Also, the present invention provides a terminal unit comprising: a 
communication unit for carrying out communication with a unit in a network; a 
storage unit; and a controller, wherein the controller comprises: (a) means for 
transmitting by the communication unit to a transmission system in the network a 
first transmission request to receive an application descriptive file from an 
information providing server in the transmission system and storing the 
application descriptive file in the storage unit, the first transmission request 
containing information on a storage location of the application descriptive file, the 
application descriptive file containing information on a storage location of an 



entity file containing software for achieving an application, and information on a 
storage location of a security descriptive file containing authorization information 
showing authorization given to an application achieved by executing the software; 
(b) means for transmitting by the communication unit to the transmission system a 
second transmission request to receive a security descriptive file, the second 
transmission request containing information on a storage location of the security 
descriptive file, contained in an application descriptive file received from the 
transmission system; (c) means for transmitting by the communication unit to the 
transmission system a third transmission request to receive an entity file from an 
information providing server in the transmission system, the third transmission 
request containing information on a storage location of the entity file contained in 
an application descriptive file received from the transmission system; and 
(d) means for restricting, when execution of software contained in an entity file 
stored in the memory unit is commanded, operation of an application achieved by 
execution of the software, in accordance with authorization information contained 
in a security descriptive file corresponding to the entity file. 
[0015] In this case, in the terminal unit, the transmission system assures 
security by transmitting to the terminal unit the security descriptive file after 
encrypting, and the controller of the terminal unit may comprise a means for 
decrypting an encrypted security descriptive file transmitted by the transmission 
system. 

[0016] Also, the controller of the terminal unit may receive the security 
descriptive file by the communication unit via a communication path whose 
security is assured. 

[0017] In this case the controller of the terminal unit may receive the security 
descriptive file by encrypted communication. 

[0018] Also, the controller of the terminal unit may receive the security 
descriptive file by the communication unit via a mobile communication network 
and an exclusive line. 



[0019] In this case, the controller of the terminal unit may receive the security 
descriptive file by encrypted communication via a mobile communication 
network. 

[0020] In a preferred embodiment, a means for restricting operation of an 
application in the controller of the terminal unit may restrict use of a resource on 
the basis of authorization information contained in the security descriptive file. 
[0021] In this case, the resource may be a hardware resource inside the 
terminal unit; a hardware resource outside the terminal unit which the terminal 
unit can use; a software resource inside the terminal unit; a software resource 
outside the terminal unit which the terminal unit can use; or a network resource 
which the terminal unit can use. 

[0022] In a preferred embodiment, means for restricting operation of an 
application in the controller of the terminal unit may determine a type of a use of a 
resource on the basis of the authorization information. 

[0023] In a preferred embodiment, a terminal unit wherein the application 
descriptive file contains a public key of a communication provider which provides 
communication service to the terminal unit, wherein the security descriptive file is 
signed by a secret key of the communication provider, and wherein the controller 
inspects authenticity of a security descriptive file transmitted by the transmission 
system using a public key contained in the application descriptive file and notifies 
a storage location of the entity file to the transmission system only when the 
authenticity is proved, is provided. 

[0024] Also, in a preferred embodiment, a terminal unit wherein the 
application descriptive file and the security descriptive file contain an application 
identifier assigned to a corresponding application, and wherein the controller 
compares an application identifier contained in an application descriptive file 
transmitted by the transmission system to an application identifier contained in a 
security descriptive file transmitted by the transmission system, and notifies a 
storage location of the entity file to the transmission system only when both 
identifiers match, is provided. 



[0025] Also, the controller of the terminal unit may notify a storage location 
of the security descriptive file to the transmission system only when a storage 
location of the security descriptive file written in the application descriptive file is 
inside the administering server unit. 

[0026] In a preferred embodiment, the security descriptive file contains time 
limit information showing an expiration date of a corresponding application, and 
the controller of the terminal unit may comprise a means for repeatedly receiving 
the security descriptive file in a chronological order from the transmission system 
by repeatedly notifying a storage location of the security descriptive file to the 
transmission system in a chronological order; and renewing an expiration date of 
the application on the basis of the time limit information contained in the security 
descriptive file repeatedly received. 

[0027] In this case, the terminal unit may renew an expiration date of the 
application only when the security descriptive file is properly transmitted from the 
transmission system. 

[0028] In a preferred embodiment, the terminal unit may be a mobile unit. 
[0029] Also, the present invention provides a transmission system comprising: 
one or a plurality of server units wherein an entity file, a security descriptive file 
and an application descriptive file are stored, the entity file containing software for 
achieving an application, the security descriptive file containing authorization 
information showing authorization given to an application achieved by executing 
the software, and application descriptive file having contents depending upon the 
entity file into which storage locations of the entity file and the security 
descriptive file are written, wherein a server unit among one or a plurality of 
server units in which the security descriptive file is stored is an administering 
server unit to which authorization for administering a security descriptive file is 
given, wherein each of the server units comprises a means for returning to an 
originator of notification a file when a storage location of the file is notified, and 
wherein the administering server unit, when a storage location of the security 
descriptive file is notified, returns the security descriptive file to an originator of 
notification with security assured. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0030] Fig. 1 is a block diagram showing the configuration of the transmission 
system of one embodiment for executing the present invention. 
[0031] Fig. 2 is a conceptual figure showing the data configuration of an ADF 
inherent to the system. 

[0032] Fig. 3 is a conceptual figure showing the data configuration of an SDF 
stored in an administering server unit in the system. 

[0033] Fig. 4 is a conceptual figure showing the content of policy information 
contained in the SDF. 

[0034] Fig. 5 is a block diagram showing the configuration of a mobile unit 
constituting the system. 

[0035] Fig. 6 is a conceptual figure showing the functional configuration of a 
mobile unit. 

[0036] Fig. 7 is a flowchart showing the process of a mobile unit for 
downloading and installing Java-AP software. 

[0037] Fig 8 is a flowchart showing the process of a mobile unit for renewing 
the expiration date of Java-AP software. 

[0038] Fig. 9 is a block diagram for explaining the operation of the 
transmission system. 

[0039] Fig. 10 is a diagram showing a list page transmitted in the transmission 
system. 

[0040] Fig. 1 1 is a diagram showing the content of an explanatory file stored 
in an IP server unit constituting the transmission system. 

[0041] Fig. 12 is a diagram showing an explanatory page transmitted in the 
transmission system. 

[0042] Fig. 13 is a diagram showing the content of an explanatory file stored 
in an IP server unit. 

[0043] Fig. 14 is a diagram showing an explanatory page transmitted in the 
transmission system. 



[0044] Fig. 15 is a diagram showing the content of an explanatory file stored 
in IP server unit 13 constituting the transmission system. 

[0045] Fig. 16 is a diagram showing an explanatory page transmitted in the 
transmission system. 

[0046] Fig. 17 is a sequence diagram for explaining the operation of the 
transmission system. 

[0047] Fig. 1 8 is a sequence diagram for explaining the operation of the 
transmission system. 

[0048] Fig. 19 is a sequence diagram for explaining the operation of the 
transmission system. 

[0049] Fig. 20 is a sequence diagram for explaining the operation of the 
transmission system. 

[0050] Fig. 21 is a diagram showing an image displayed in a mobile unit. 
[0051] Fig. 22 is a block diagram for explaining another operation of the 
transmission system. 

[0052] Fig. 23 is a sequence diagram for explaining another operation of the 
transmission system. 

[0053] Fig. 24 is a diagram showing the configuration within the controller of 
a mobile unit, which carries out a process for inquiring the validity of the SDF. 
[0054] Fig. 25 is a time-chart showing the operation of inquiring the validity 
of the SDF. 

DETAILED DESCRIPTION OF THE DRAWINGS AND THE 
PRESENTLY PREFERRED EMBODIMENTS 

[0055] Hereinafter, by referring to figures, a transmission system, which is 
one mode of the present invention, is explained. In figures, identical codes are 
given to parts that are common. 

(1) Configuration 

[0056] As shown in Fig. 1, in the transmission system, IP server units 12 to 14 
are connected to Internet 1 1. IP server unit 12 is administered by the first IP 
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(Internet Provider), and IP server units 13 and 14 are administered by the second 
IP, which differs from the first IP. IP server units 12 to 14 constitute WWW, and 
each is equipped with similar hardware and functions to those of a general WWW 
server unit. Mobile packet communication network 15 is a network a 
communication provider uses to provide a mobile packet communication service. 
Mobile unit 16 can perform radio packet communication with mobile packet 
communication network 15. Gateway server unit 17 is administered by the same 
communication provider as that of mobile packet communication network 15. 
Gateway server unit 17 is a unit for connecting mobile packet communication 
network 15 and Internet 11, and has similar configuration to that of a general 
gateway server unit. Administering server unit 1 8 is connected to gateway server 
unit 17 by an exclusive line. Administering server unit 18 also constitutes WWW, 
and has similar hardware and a function to those of a general WWW unit. 
Gateway server unit 17 performs packet communication between mobile packet 
communication network 15 and Internet 11, packet communication between 
administering server unit 18 and mobile packet communication network 15, and 
packet communication between administering server unit 18 and Internet 11. 
Mobile unit 16, by using the relaying function, is able to perform packet 
communication with IP server units 12 to 14 via mobile packet communication 
network 15 and Internet 11. Several mobile units exist in the actual transmission 
system, but only one mobile unit 16 is shown to avoid complicating the figures. 
For the same reason, only IP server units 12 to 14 are shown. 
[0057] In the transmission system, mobile unit 16 is capable of receiving 
Java-AP software from the desired site on Internet 11. Software which mobile 
unit 16 is capable of receiving is distinguished between the one pertaining to a 
trusted Java-AP and the one pertaining to a non-trusted Java-AP. A trusted Java- 
AP software is one, which the communication provider administering mobile 
packet communication network 15 guarantees authenticity of on the basis of the 
contract with IP administering IP server units 12 to 14. A non-trusted Java-AP 
software is any Java-AP software other than a trusted Java-AP software. 
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[0058] Administering server unit 18 stores each SDF (Security Descriptive 
File) pertaining to each trusted Java-AP software, which is transmitted in the 
transmission system. SDF is a file, which is produced by the communication 
provider administering mobile packet communication network 15, and is the file 
necessary for downloading into a mobile unit the Java-AP software, which uses 
trusted API (Application Interface) of the mobile unit. An explanation of trusted 
API will follow later. As shown in Fig. 3, SDF contains APID for detecting 
trusted Java-AP software, policy information, and the expiration date. The 
information is encrypted by a secret key of a communication provider. Policy 
information is the information showing restriction on the operation of trusted Java- 
AP in mobile unit 16. Policy information and the restriction on Java-AP' s 
operation carried out on the basis of the policy information will be explained in 
detail afterwards. 

[0059] In the present embodiment, when a request is sent for transmission of 
trusted Java-AP Software that mobile unit 16 desires, ADF corresponding to the 
trusted Java-AP software is transmitted to mobile unit 16 from one of IP server 
units 12-14. At this stage, in ADF of trusted Java-AP software are contained URL 
showing the location of the Jar file, URL showing the location of SDF 
corresponding to trusted Java-AP software, and the public key paired with the 
secret key which is used to encrypt SDF. Mobile unit 16 obtains SDF by using 
URL in ADF after receiving ADF, and decrypts SDF by using the public key in 
ADF. Then, mobile unit 16 finally obtains the Jar file by using URL of the Jar file 
contained in ADF. Hereinafter, when trusted Java-AP software is executed in 
mobile unit 16, the operation of trusted Java-AP is restricted on the basis of SDF. 
This is one characteristic of the present embodiment. As shown in Fig. 1, 
transmission of SDF is carried out via mobile packet communication network 15, 
and administering server unit 18 and gateway server unit 17, which are connected 
by an exclusive line. 

[0060] Hereinafter, with regard to the relevant characteristics, the 
configuration of each element of the transmission system will be explained. 
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[0061] IP server units 12, 13 and 14 are equipped with fixed memory 12A, 
13 A and 14A respectively. 

[0062] Fixed memory 12 A, 13 A and 14A are fixed memories such as a hard 
disc, and store Java-AP software constituting Jar files and ADF, and explanatory 
files on the content of Java-AP software for users of mobile units. 
[0063] Each Java-AP software stored in fixed memory 12 A, 13 A and 14A 
might be either trusted Java-AP software or non-trusted Java AP software. 
Whether Java-AP is trusted Java-AP or non-trusted Java-AP, in each ADF of Java- 
AP software, information such as a package URL showing the location where a Jar 
file in WWW is stored, information showing the size of the Jar file, and 
information showing the date of the most recent update are written. Such 
information is generally known as items to be written in ADF of a Java-AP 
software. Also, ADF of trusted Java-AP software, as shown in Fig. 2, contains 
APID of trusted Java-AP, the hash value of the Jar file, URL showing the location 
where SDF is stored in WWW (hereinafter, referred to as SDF-URL), and the 
public key paired with the secret key used for encrypting SDF. At this stage, the 
public key is issued to a communication provider whose authenticity is certified by 
CA (Certifying Agent) as a certificate. 

[0064] Also, the explanatory file is a text file written in accordance with 
HTML. A mobile unit, when a certain Java-AP software is downloaded, needs to 
download beforehand, the explanatory file corresponding to the Java-AP software. 
The explanatory file contains information for forming UI (User Interface) for 
receiving from the user the command for downloading Java-AP software. Mobile 
unit 16 displays the UI screen in accordance with the information. The user can 
carry out the operation on mobile unit 16 for specifying the object showing the 
desired Java-AP on the UI screen. The explanatory file is written for the object 
specified by the user in this manner so as to correspond to the URL showing 
where in WWW, ADF corresponding to Java-AP software, which is the object for 
downloading, is located. 
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[0065] Each of IP server units 12 to 14 is equipped with the function of 
producing and updating each of the above-mentioned files in accordance with the 
command of an IP. 

[0066] Administering server unit 18 is equipped with fixed memory 18A such 
as a hard disc. Administering server unit 18 establishes a TCP connection with the 
party. When administering server unit 18 receives a request message which uses 
the GET method of HTTP from the party via a TCP connection, administering 
server unit 18 reads out the file identified by URL specified by GET method from 
fixed memory 18 A, and returns a response message of HTTP containing the file, 
and severs the connection. 

[0067] Also, in the above-mentioned fixed memory 18A are stored, list 
file 200 for introducing to the user of mobile unit 16 downloadable Java-AP 
software, and respective SDF corresponding to each Java-AP software which is 
listed in list file 200. 

[0068] SDF has already been explained by referring to Fig. 3. 
[0069] List file 200, is a text file written in accordance with HTML. As 
already explained, the mobile unit, when it needs to download certain Java-AP 
software, needs to obtain the explanatory file relating to the Java-AP software. As 
already explained, mobile unit 16 can obtain the explanatory file directly by 
accessing the IP server unit in which the explanatory file is stored. However, in 
the present embodiment, mobile unit 16 can obtain the explanatory file of the 
desired Java-AP software also by the following process as opposed to the above- 
mentioned direct method. First, mobile unit 16, by accessing administering server 
unit 18, obtains list file 200, and displays UI screen accordingly. The user can 
carry out the operation on mobile unit 16 to specify the object showing the desired 
Java-AP on UI screen. List file 200 matches the object specified by the user to 
URL showing the location of the explanatory file of Java-AP software in WWW, 
which is the object of downloading. Mobile unit 16, by using URL obtained via 
list file 200, obtains the explanatory file from the IP server unit. 
[0070] Mobile unit 16 consists of, as shown in Fig. 5, OS (Operating System) 
software; ROM 16A in which Java-AP environment software for establishing the 



• 1 ■ 



14 

environment for executing Java-AP, and several types of native AP software are 
stored; CPU 16B which is connected to ROM 16A for reading out a program from 
ROM 16A and executing the program; displaying unit 16C which is connected to 
CPU 16B; fixed memory 16D; RAM 16E; communication unit 16F; and operation 
unit 16G. 

[0071] Displaying unit 16C has, for example, a liquid crystal displaying panel, 
and displays data provided by CPU 16B as an image. Fixed memory 16D is, for 
example, SRAM or EEPROM, and data is read and written by CPU 16B. Fixed 
memory 16D is used to store Java-AP software downloaded from a server unit 
(hereinafter, referred to as a Web server unit) constituting WWW, and SDF. As 
already explained, in the present embodiment, the expression "Java-AP software" 
is used to refer to both "trusted Java-AP software" and "non-trusted Java-AP 
software." However, in a certain context, the expression "Java-AP software" may 
refer to "trusted Java-AP software." In such a context, the expression "Java-AP 
software" should be interpreted as a concept containing ADF, SDF, and Jar. Also, 
in a certain context, the expression "Java-AP software" may refer to "non-trusted 
Java-AP software." In such a context, the expression "Java-AP software" should 
be interpreted as a concept containing ADF and Jar. 

[0072] Communication unit 16F performs radio packet communication with 
mobile packet communication network 15, and relays packets between CPU 16B 
and mobile packet communication network 15. Also, communication unit 16F is 
equipped with CODEC, a microphone, a speaker and so forth for communication 
besides an antenna or a radio transmission and reception unit. Hence, mobile 
unit 16, by communication unit 16F, can perform communication by circuit 
switching via a mobile communication network (not shown). Operation unit 16G 
is equipped with an operation controller, and provides CPU 16B a signal in 
accordance with the operation carried out by the operation controller. Timer 
unit 16H clocks the present date and time (hereinafter, merely referred to as the 
present date and hour). For timer unit 16H to clock the present date and hour 
more precisely, the present date and hour may be synchronized with the present 
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date and hour notified periodically via a control channel by a base station of 
packet communication network 15 (not shown). 

[0073] CPU 16B is a unit, which controls the entire mobile unit 16 in 
accordance with several kinds of programs stored in ROM 16 A. When a switch 
(not shown) is turned on, CPU 16B reads out OS of Fig. 6 from ROM 16A and 
executes with RAM 16E as a work area. CPU 16 provides a function such as UI 
in accordance with OS. OS identifies the command of the user on the basis of the 
signal supplied by operation unit 16G and the status of UI, and carries out the 
process in accordance with the command. 

[0074] When the command of the user requests activation of communication 
software, which is native AP software, OS activates the communication software, 
and executes communication AP in mobile unit 16. By using communication AP, 
the user can communicate with the party. 

[0075] When the command of the user requests the activation of telephone 
directory AP, which is native AP software, OS activates the telephone directory 
software, and executes telephone directory AP in mobile unit 16. By using 
telephone directory AP, the user can refer to, use, and change the content of the 
telephone directory (hereinafter, referred to as telephone directory data) stored in 
fixed memory 16D. 

[0076] When the command of the user requests the activation of Web browser 
software, which is native AP software, OS activates Web browser software, and 
executes the Web browser in mobile unit 16. The Web browser provides UI. 
Then, as the user gives the command by operating operation unit 16G, the Web 
browser identifies the command of the user on the basis of the status of UI and the 
signal provided by operation unit 16G, and executes the process in accordance 
with the command. For example, when the command is for obtaining the 
specified file from WWW, a TCP connection is established by operating 
communication unit 16F with the Web server unit in which the file is stored, a 
request message of HTTP using the GET method is transmitted by URL showing 
the specified location, a response message corresponding to the request message is 
received, and the connection is severed. Furthermore, the Web browser interprets 
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the file contained in the received response message in accordance with HTML, 
produces UI containing the Web page, and provides the user. Also, when a user 
sends a command for downloading Java-AP software, Web browser notifies the 
command to JAM (Java Application Manager). Specifically, in a Web page, 
either by clicking or pressing, when an anchor tag to which the object tag is 
specified is designated, the Web browser extracts URL which is specified as data 
property of the object tag, and notifies JAM that downloading of Java-AP software 
by URL is requested. 

[0077] When the command of the user requests the activation of JAM 
software, which is native AP software, OS activates JAM software, and executes 
JAM in mobile unit 16. JAM shows to the user a list of Java-AP software 
installed in mobile unit 16, and activates the Java-AP software specified by the 
user. Specifically, when the command of the user to JAM requests the activation 
of Java-AP software, Java-AP environment software is activated, and Java-AP 
environment is executed in mobile unit 16. Then, the specified Java-AP software 
is activated, and Java-AP is executed in Java-AP environment. Java-AP 
environment contains KVM, which is a lightweight Java Virtual Machine 
appropriate to a cellular terminal, and API provided for Java-AP. API provided 
for Java-AP is divided into trusted API which only Java-AP whose trustworthiness 
is guaranteed by the communication provider on the basis of the contract with the 
IP (hereinafter, referred to as trusted AP) is allowed to use, and non-trusted API 
which any Java-AP is allowed to use. 

(2) Operation 

[0078] Hereinafter, the operation of the present embodiment is explained. 
(2-1) Download of Java-AP Software by Mobile unit 16 

[0079] JAM, when a command for requesting the downloading of Java-AP is 
notified by the Web browser, carries out the process for downloading and 
installing Java-AP software into mobile unit 16. The flow of the process is shown 
in Fig. 7. In Fig. 7, the process of mobile unit 16 for obtaining the explanatory file 
is omitted. Since different modes exist for the process of obtaining the 
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explanatory file, the process will be later explained with specific examples of the 
operation. As shown in Fig. 7, JAM first determines whether downloading of 
Java-AP software is requested (Step SI 1). Then, when a command for requesting 
downloading of Java-AP software is notified from Web browser, ADF 
corresponding to the Java-AP software is obtained from any one of IP server 
units 12-14 (Step S 12). More specifically, JAM establishes a TCP connection 
with any one of IP server units 12-14 in which ADF is stored, produces and 
transmits a request message requesting transmission of ADF, and severs the TCP 
connections after receiving a response message to the request message and 
obtaining ADF. Then, JAM writes ADF contained in the response message into 
fixed memory 16D. 

[0080] Then, JAM determines whether Java-AP software, which is about to be 
downloaded, can be installed in mobile unit 16 on the basis of the content of ADF 
(Step S 13). At this stage, whether installation is possible or not, may be 
determined on the same basis as a conventional basis such as comparison between 
the size of the Jar file written in ADF and the available volume in fixed 
memory 16D in which the Jar file can be stored. 

[0081] At this stage, when installation is determined to be possible (Step S 13; 
Yes), JAM determines whether Java-AP software, which is about to be 
downloaded, is trusted Java-AP software (Step S 14). More specifically, JAM 
confirms whether SDF-URL is written in ADF obtained in Step S 12, and 
determines that SDF corresponding to the Java-AP software exists when SDF- 
URL is written. In other words, JAM determines that Java-AP software is trusted 
Java-AP software. On the other hand, JAM determines that Java-AP software is 
non-trusted Java-AP software when SDF-URL is not written. 
[0082] Then, when Java-AP software, which is about to be downloaded is 
determined to be non-trusted Java-AP (Step S 14; No), the conventional processes 
for downloading and installation are carried out (Step S 15). 
[0083] On the other hand, when Java-AP software, which is about to be 
downloaded, is determined to be trusted Java-AP software (Step S 14; Yes), JAM 
obtains SDF corresponding to the software from administering server unit 1 8 (Step 
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S 16). In other words, JAM establishes a TCP connection with administering 
server unit 18, produces and transmits a request message for requesting 
administering server unit 18 to transmit SDF stored in the location shown by SDF- 
URL written in ADF, and severs the above-mentioned connection after receiving a 
response message to the request message and obtaining- SDF. 
[0084] As mentioned above, SDF corresponding to trusted Java-AP software 
contains APID, policy information, and the expiration date. SDF is further signed 
(encrypted) with the secret key of the communication provider. Then, JAM 
inspects (decrypts) the signature of SDF contained in the response message by 
using the public key extracted from ADF which has already been obtained, and 
determines the authenticity of SDF (Step S 17). When the authenticity is 
confirmed (Step S 17; Yes), JAM writes SDF into fixed memory 16D. 
[0085] Then, JAM compares APID contained in SDF with APID contained in 
ADF, which has already been obtained, and determines whether the APIDs match 
(StepS 18). 

[0086] When the APIDs are determined to match (Step S 18; Yes), JAM 
obtains the Jar file (Step S 19). More specifically, JAM establishes a TCP 
connection with any one of IP servers 12-14 in which the Jar file identified by 
package URL contained in ADF is stored; produces and transmits a request 
message to request transmission of the Jar file; receives a response message to the 
request message; obtains the Jar file; and severs the TCP connection. 
[0087] Then, JAM calculates the hash value of the Jar file obtained (Step 
S 20). Although any hash function can be used to calculate the hash value, the 
hash function used in mobile unit 16 and the hash function used to calculate the 
hash value contained in ADF must be identical. IP, which provides trusted Java- 
AP software actually calculates the hash value by the hash function used in mobile 
unit 16, and produces ADF. 

[0088] JAM compares the hash value calculated and the hash value extracted 
from ADF, and when the hash values match (Step S 21; Yes), writes the obtained 
Jar file into fixed memory 16D, carries out several kinds of processes relating to 
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the installation of trusted Java-AP software (Step S 22), and notifies to the user 
that the installation has succeeded (Step S 23). 

[0089] Hereinafter, JAM monitors the operation of trusted Java-AP when 
trusted Java-AP software is executed, and restricts the use of trusted API. The 
restriction is carried out in accordance with policy information in SDF stored in 
fixed memory 16D. 

[0090] When Java-AP software is determined to be not installable (Step S 13; 
No); SDF is determined to be not authentic (Step S 17; No), APID of SDF and 
APID of ADF do not match (Step S 18; No); or the hash value calculated and the 
hash value ADF has do not match (Step S 21; No), JAM notifies to the user that 
the installation has failed, and returns the status of mobile unit 16 to that of Step 
S 1 1 or that of before Step S 1 1 . 

(2-2) Renewal of SDF by Mobile Unit 16 

[0091] Trusted Java-AP software can be executed by mobile unit 16 until the 
expiration date contained in the corresponding SDF passes. When the expiration 
date needs to be renewed, mobile unit 16 needs to obtain new SDF from 
administering server unit 18. Hereinafter, the process of JAM for renewing the 
expiration whenever the expiration date in SDF is reached is explained by 
referring to the flow chart shown in Fig. 8. 

[0092] As shown in Fig. 8, JAM constantly monitors the present date and hour 
clocked by timer unit 16H in mobile unit 16 and a plurality of expiration dates 
each of which is extracted from all SDF obtained so far and stored in fixed 
memory 16D; and determines whether the expiration date is reached (Step S 31). 
[0093] When any one reaches the expiration date (Step S 31; Yes), JAM 
displays a message on displaying unit 16C to ask the user whether to renew the 
expiration date along with the name of the Java-AP software whose expiration 
date is reached, and waits until the user carries out the necessary operation. 
[0094] When the user commands to renew the expiration date, JAM interprets 
the content of the command (Step S 32; Yes), and obtains SDF corresponding to 
the Java-AP software whose expiration date should be renewed, from 



20 



administering server unit 18 (Step S 33). More specifically, JAM refers to the 
memory content of fixed memory 16D; extracts SDF-URL contained in ADF 
which contains APID of the Java-AP software whose expiration date should be 
renewed; produces and transmits a request message to request administering server 
unit 18 the transmission of SDF stored in the location shown in SDF-URL; and 
severs the above-mentioned connection after receiving a response message to the 
request message and obtaining SDF. 

[0095] Then, JAM determines whether SDF is obtained by using the above- 
mentioned SDF-URL (Step S 34). At this stage, in a case that SDF cannot be 
obtained it is because the communication provider does not store SDF in the 
location shown by the above-mentioned SDF-URL in administering server 18; or 
because the communication provider wants to stop or discontinue the use of Java- 
AP software for a certain reason. The reason the use of Java-AP software needs to 
be stopped or discontinued could be due to circumstances pertaining to IP (for 
example, when transmitting software a user can try only for a certain period of 
time), or if the contract between IP and the communication provider has expired. 
[0096] When JAM succeeds in obtaining SDF (Step S 34; Yes), JAM inspects 
(decrypts) the signature of SDF by using the public key contained in ADF, which 
has already been obtained, and determines the authenticity of SDF (Step S 35). 
[0097] When the authenticity is confirmed (Step S 35; Yes), JAM compares 
APID contained in SDF with APID contained in ADF which has already been 
obtained, and determines whether the APIDs match (Step S 36). When the APIDs 
are determined to match (Step S 36; Yes), JAM writes the obtained SDF over the 
previous SDF which has already been written into fixed memory 16D, and renews 
the expiration date in this manner. 

[0098] In the instances when the expiration date is determined not to be 
renewed by the operation of the user (Step S32; No); when SDF cannot be 
obtained (Step S34; No); when SDF is determined to be not authentic (Step S 35; 
No); or when APID of SDF and APID of ADF do not match (Step S 36; No), JAM 
notifies to the user that the expiration date will not be renewed, and returns the 
status of mobile unit 16 to that of Step S 31 or before. 
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(3) Specific Operation 

[0099] Next, the operation of the above-mentioned system is explained. 
[00100] In the operation explained below, establishment of the TCP connection 
and severing operation are general operations of HTTP; therefore, the explanation 
is omitted. Also, the above-mentioned operations carried out by OS, the Web 
browser, JAM, Java-AP, native AP and so forth are operations of mobile unit 16; 
therefore, in the following explanation, the main unit which carries out the 
operation is mobile unit 16. 

[00101] Also, as shown in Fig. 9, in fixed memory 18A of administering server 
unit 18, are stored list file 200 and SDF 204. List file 200 and SDF 204 are 
produced by the communication provider in accordance with the contract between 
IP, which administers IP server unit 13 and IP server unit 14, and the 
communication provider, which administers administering server unit 18. 
[00102] At this stage, list file 200 is written to provide list page 201 shown in 
Fig. 10 when interpreted and executed by mobile unit 16. Also, list file 200 is 
written, when option 201 A constituting list page 201 is hit (either by being clicked 
or pressed), to produce a request message containing URL of explanatory file 202 
(will be explained later) ("http://www.main.bbb.co.jp/ghi.html") as a parameter of 
the GET method. Moreover, list file 200 is written, when option 20 IB 
constituting list page 201 is hit (either by being clicked or pressed), to produce a 
request message containing URL of explanatory file 207 (will be explained later) 
("http://www.ccc.co.jp/jkl.html") as a parameter of the GET method. 
[00103] Also, SDF 204 contains "0001" as APID, information shown in Fig. 4 
as policy information, and "10:00 AM of October 1, 2002" as the expiration date 
which are signed by using the secret key of the communication provider. 
[00104] Also, in fixed memory 12A of IP server unit 12, are stored explanatory 
file 211 corresponding to Java-AP software of the title "tsume-shogi" (hereinafter, 
referred to as the first non-trusted Java-JP software in the present embodiment), 
ADF 213, and Jar file 214. Explanatory file 211, ADF 213, and Jar file 214 are 
produced by IP administering IP server unit 12. With regard to these files, the 
content of explanatory file 21 1 is shown in Fig. 11, and explanatory file 21 1 is 
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written to provide explanatory page 212 shown in Fig. 12 when interpreted and 
executed by mobile unit 16. Also, ADF 213 contains URL of Jar file 214 
("http://www.ccc.cojp/shogi.jar") as package URL. 

[00105] Also, in fixed memory 12A of IP server unit 12, are stored explanatory 
file 207 corresponding to Java-AP software of the title "horoscope" (hereinafter, 
referred to as the second non-trusted Java-AP software in the present 
embodiment), ADF 209, and Jar file 210. Explanatory file 207, ADF 209, and Jar 
file 210 are produced by IP administering IP server unit 12. With regard to these 
files, the content of explanatory file 207 is shown in Fig. 13, and explanatory 
file 207 is written to provide explanatory page 208 shown in Fig. 14 when 
interpreted and executed by mobile unit 16. Also, ADF 209 contains URL of Jar 
file 210 ("http://www.ccc.co.jp/horoscope.jar") as package URL. 
[00106] The above-mentioned first non-trusted Java-AP software and the 
second non-trusted Java-AP software are different in that information on the 
second non-trusted Java-AP software is registered with list file 200, whereas 
information on the first non-trusted Java-AP software is not registered. 
[00107] Also, in fixed memory 13 A of IP server unit 13, are stored explanatory 
file 202 corresponding to Java-AP software of the title "telephone number 
directory viewer" (hereinafter, referred to as trusted Java-AP software in the 
present embodiment), ADF 205, and Jar file 206. Explanatory file 202, ADF 205, 
and Jar file 206 are produced by IP administering IP server unit 13 and IP server 
unit 14. With regard to these files, the content of explanatory file 202 is shown in 
Fig. 15, and explanatory file 202 is written to provide explanatory page 203 shown 
in Fig. 16 when interpreted and executed by mobile unit 16. ADF 205 contains 
"0001" as APID, the hash value of Jar file 206 as a hash value, URL of Jar file 206 
("http://www.main.bbb.co.jp/viewer.jar") as package URL, and URL of SDF 204 
(http://www.aaa.co.jp/viewer.sdf) as SDF-URL, and the public key of the 
communication provider. Also, mobile unit 16 is in the status in which each of the 
above-mentioned Java-AP software can be installed. 
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(3-1) Installation Operation 

[00108] First, the operation of installing Java-AP software in mobile unit 16 is 
explained with reference to each of the above-mentioned Java-AP software. 

(3-1-1) First Non-Trusted Java-AP Software 

[00109] The installation operation of the first non-trusted Java-AP software 
begins when the user tries to obtain explanatory file 21 1 by operating mobile 
unit 16. As a result, in mobile unit 16, request message tm 12 containing URL of 
explanatory file 211 ("http://www.ccc.co.jp/mno.html") as a parameter of the GET 
method is produced. Request message tm 12 is, as shown in Fig. 17, transmitted 
by mobile unit 16, and is received by IP server unit 12. 

[00110] In IP server unit 12, response message tm 13 containing explanatory 
file 21 1 is produced in response to the content of request message tm 12. 
Response message tm 13 is transmitted by IP server unit 12, and is received by 
mobile unit 16. In mobile unit 16, UI corresponding to the content of explanatory 
file 21 1 is provided to the user. As a result, in displaying unit 16C, explanatory 
page 212 shown, for example, in Fig. 12 is displayed. 

[00111] When the user sees explanatory page 212, and operates mobile unit 16 
to hit anchor 212A in explanatory page 212, the value specified as ijam property 
of the anchor tag written in explanatory file 21 1 of Fig. 1 1 (the tag which begins 
with "<A") identifies the object tag specified as id property (the tag which begins 
with "<OBJECT") in mobile unit 16. Then, URL specified as data property of the 
object tag ("http://www. ccc.co.jp/shogi.jam") is extracted, and request message 
tml6 requesting transmission of ADF 213 identified by the URL is produced. 
Request message tml6 is transmitted from mobile unit 16, and is received by IP 
server unit 12. 

[00112] In IP server unit 12, response message tml7 containing ADF 213 
corresponding to the content of request message tm 16 is produced. Response 
message tm 17 is transmitted from IP server unit 12, and is received by mobile 
unit 16. 
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[00113] In mobile unit 16, on the basis of the content of ADF 213, whether the 
first non-trusted Java-AP software can be installed is determined. As mentioned 
above, since mobile unit 16 is in the status in which non-trusted Java-AP software 
can be installed, installation of the first non-trusted Java-AP software is 
determined to be possible in mobile unit 16. 

[00114] Then, in mobile unit 16, ADF 213 is written into fixed memory 16D. 
Also, in mobile unit 16, package URL ("http://www.ccc.co.jp/shogijar") is 
extracted from ADF 213, and request message tm 18 requesting transmission of 
Jar file 214 identified by the package URL is produced. Request message tm 18 is 
transmitted by mobile unit 16, and is received by IP server unit 12. 
[00115] In IP server unit 12, response message tm 19 containing Jar file 214 is 
produced in response to the content of request message tm 18. Response message 
tm 19 is transmitted by IP server unit 12, and is received by mobile unit 16. In 
mobile unit 16, Jar file 214 is written into fixed memory 16D in the status in 
which activation is possible, and installation of the first non-trusted Java-AP 
software is completed. 

[00116] When the first non-trusted Java-AP software is determined as not 
installable in mobile unit 16, the status of mobile unit 16 returns to the status that 
existed before the acquisition of ADF 213 began. 

(3-1-2) Second Non-Trusted Java-AP software 

[00117] The installation operation of the second non-trusted Java-AP software 
begins when the user tries to obtain explanatory file 207 or list file 200 by 
operating mobile unit 16. The operation, which begins by trying to obtain 
explanatory file 207 is a subset of the operation, which begins by trying to obtain 
list file 200; therefore, only the operation, which begins by trying to obtain list 
file 200 is explained hereinafter. 

[00118] As shown in Fig. 18, in mobile unit 16, request message tm 20 
containing URL of list file 200 ("http://www.aaa.co.jp/def.html") as a parameter 
of the GET method is produced. Request message tm 20 is transmitted by mobile 
unit 16, and is received by administering server unit 18. 
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[00119] In administering server unit 18, response message tm 21 containing list 
file 200 is produced in response to the content of request message tm 20. 
Response message tm 21 is transmitted by administering server unit 18, and is 
received by mobile unit 16. In mobile unit 16, when response message tm 21 is 
received, list file 200 in response message tm 21 is interpreted in accordance with 
HTML, and UI corresponding to the content of list file 200 is provided to the user 
of mobile unit 16. As a result, in displaying unit 16C of mobile unit 16, list 
page 201 shown, for example, in Fig. 10 is displayed. 

[00120] When the user, after seeing list page 201, operates mobile unit 16 to hit 
option 20 IB in list page 201, request message tm 22 containing URL 
("http://www.ccc.co.jp.jkl.html") corresponding to option 201 B as a parameter of 
the GET method is produced. Request message tm 22 is transmitted by mobile 
unit 16, and is received by IP server unit 12. 

[00121] In IP server unit 12, response message tm 23 containing explanatory 
file 207 is produced in response to the content of request message tm 22. 
Response message tm 23 is transmitted by IP server unit 12, and is received by 
mobile unit 16. In mobile unit 16, UI corresponding to the content of explanatory 
file 207 is provided to the user. As a result, in displaying unit 16C, explanatory 
page 208 shown, for example, in Fig. 14 is displayed. 

[00122] When the user, after seeing explanatory page 208, operates mobile 
unit 16 to hit anchor 208A in explanatory page 208, the value specified as ijam 
property of the anchor tag written in explanatory file 207 of Fig. 13 (the tag which 
begins with "<A") identifies the object tag specified as id property (the tag which 
begins with "<OBJECT"). Then, URL specified as data property of the object tag 
("http://www. ccc.co.jp/horoscope.jam") is extracted, and request message tm 26 
requesting transmission of ADF 209 identified by the URL is produced. Request 
message tm 26 is transmitted by mobile unit 16, and is received by IP server 
unit 12. 

[00123] In IP server unit 12, response message tm 27 containing ADF 209 
corresponding to the content of request message tm 26 is produced. Response 
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message tm 27 is transmitted by IP server unit 12, and is received by mobile 
unit 16. 

[00124] In mobile unit 16, on the basis of the content of ADF 209, whether the 
second non-trusted Java-AP software can be installed is determined. As 
mentioned above, since mobile unit 16 is in the status in which the second non- 
trusted Java-AP software can be installed, the second non-trusted Java-AP 
software is determined as installable in mobile unit 16. 

[00125] Next, in mobile unit 16, ADF 209 is written into fixed memory 16D. 
Also, in mobile unit 16, package URL ("http://www.ccc.co.jp/horoscope.jar") is 
extracted from ADF 209, and request message tm 28 requesting transmission of 
jar file 210 identified by package URL is produced. Request message tm 28 is 
transmitted by mobile unit 16, and is received by IP server unit 12. 
[00126] In IP server unit 12, response message tm 29 containing Jar file 210 in 
response to the content of request message tm 28 is produced. Response message 
tm 29 is transmitted by IP server unit 12, and is received by mobile unit 16. In 
mobile unit 16, Jar file 210 is written into fixed memory 16D, and installation of 
the second Java-AP software is completed. 

[00127] When the second Java-AP software is determined as not installable in 
mobile unit 16, the status of mobile unit 16 returns to a previous status, that which 
existed before the acquisition of ADF 209 began. 

(3-1-3) Trusted Java-AP Software 

[00128] The installation operation of the trusted Java-AP software begins when 
the user tries to obtain explanatory file 202 or list file 200 by operating mobile 
unit 16. The operation, which begins by trying to obtain explanatory file 202 is a 
subset of the operation, which begins by trying to obtain list file 200; therefore, the 
operation, which begins by trying to obtain explanatory file 202 is omitted. 
[00129] As shown in Fig. 19, in the operation which begins by trying to obtain 
list file 200, an operation identical to the operation shown in Fig. 18 is carried out 
till list page 201 shown, for example, in Fig. 10 is displayed after mobile unit 16 
receives response message tm 21. When the user, after seeing list page 201, 
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operates mobile unit 16 to hit option 201 A in list page 201, request message tm 32 
containing URL corresponding to option 201 A 

( tc http://www.main.bbb. co.jp/ghi.html") as a parameter of the GET method is 
produced in mobile unit 16. Request message tm 32 is transmitted by mobile 
unit 16, and is received by IP server unit 13. 

[00130] In IP server unit 13, response message tm 33 containing explanatory 
file 202 in response to the content of request message tm 32 is produced. 
Response message tm 33 is transmitted by IP server unit 13, and is received by 
mobile unit 16. In mobile unit 16, the user is provided with UI corresponding to 
the content of explanatory file 202. As a result, in displaying unit 16C, 
explanatory page 203 shown, for example, in Fig. 16 is displayed. 
[00131] When the user, after seeing explanatory page 203, operates mobile 
unit 16 to hit anchor 203 A in explanatory page 203, the value specified as ijam 
property of the anchor tag written in explanatory file 202 in Fig. 15 (the tag which 
begins with "<A") identifies the object tag specified as id property (the tag which 
begins by "<OBJECT"). Then, URL specified as data property of the object tag 
("http://www.main.bbb.co.jp/viewer.jam") is extracted, and request message tm 34 
requesting transmission of ADF identified by the URL is produced. Request 
message tm 34 is transmitted from mobile unit 16, and is received by IP server 
unit 13. In IP server unit 13, response message tm 35 containing ADF 205 
corresponding to the content of request message tm 34 is produced. Response 
message tm 35 is transmitted from IP server unit 13, and is received by mobile 
unit 16 via gateway server unit 17 and mobile packet communication network 15. 
[00132] In mobile unit 16, ADF 205 is written into fixed memory 16D, and 
whether trusted Java-AP software is installable is determined on the basis of the 
content of ADF 205. As mentioned above, since mobile unit 16 is in the status in 
which trusted Java-AP software is installable, trusted Java-AP software is 
determined to be installable in mobile unit 16. 

[00133] Then, in mobile unit 16, request message tm 36 requesting 
transmission of SDF 204 identified by SDF-URL 

"http://www.aaa.co.jp/viewer.sdf contained in ADF 205 is produced. Request 
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message tm 36 is transmitted from mobile unit 16, and is received by 
administering server unit 18. 

[00134] In administering server unit 18, response message tm 37 containing 
SDF 204 corresponding to the content of request message tm 36 is produced. 
Response message tm 37 is transmitted from administering server unit 18, and is 
received by mobile unit 16 via gateway server unit 17 and mobile packet 
communication network 15. At this stage, the communication path between 
administering server unit 18 and gateway server unit 17 is an exclusive line, and 
SDF 204 cannot be falsified until SDF 204 is received by mobile unit 1 6 since 
gateway server unit 17 is directly connected to mobile packet communication 
network 15 whose security is assured. 

[00135] Further, in mobile unit 16, the authenticity of SDF 204 is determined 
by using the public key contained in ADF 205. As mentioned above, the public 
key contained in ADF 205 corresponds to the secret key used for signing 
SDF 204; therefore, SDF 204 is determined to be authentic as long as the content 
of SDF 204 is not changed in administering server unit 18. 

[00136] When SDF 204 is determined to be authentic, in mobile unit 16, APID 
contained in ADF 205 and APID contained in SDF 205 are compared. As 
mentioned above, since APID, which corresponds to APID in SDF 204 is 
specified to be written in ADF 205 in IP server unit 13, APID contained in 
ADF 205 and APID contained in SDF 204 match as long as no mistakes exist in 
description and so forth. Then, in mobile unit 16, SDF 204 is written into fixed 
memory 16D. 

[00137] Next, in mobile unit 16, package URL ( http://www.main.bbb.co.jp / 
viewer .jar) is extracted from ADF 205, and request message tm 38 requesting 
transmission Jar file 206 identified by the package URL is produced. Request 
message tm 38 is transmitted from mobile unit 16, and is received by IP server 
unit 13. 

[00138] In IP server unit 13, response message tm 39 containing Jar file 206 
corresponding to the content of request message tm 38 is produced. Response 
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message tm 39 is transmitted from IP server unit 13, and is received by mobile 
unit 16. 

[00139] Then, in mobile unit 16, the hash value is calculated by using the hash 
function of Jar file 206 and the specified hash function, and the calculated hash 
value and the hash value contained in ADF 205 are compared. As mentioned 
above, since the hash value of the Jar file corresponding to ADF 205 is specified 
to be written into ADF 205, the hash values match as long as no mistakes exist in 
description and so forth. 

[00140] When the hash values match, in mobile unit 16, Jar file 206 is written 
into fixed memory 16D in the status in which activation is possible, and 
installation of trusted Java-AP software is completed. 

[00141] When SDF 204 is determined to be not authentic in mobile unit 16; 
APID contained in ADF 205 and APID contained in SDF 204 do not match; 
trusted Java-AP software is determined to be not installable; or the hash value 
calculated and the hash value contained in ADF 205 do not match, the status of 
mobile unit 16 returns to that existing before the acquisition of SDF 205 begins. 

(3-2) Operation of Mobile Unit 16 When Java-AP Software Is Activated 
[00142] Next, the operation of mobile unit 16 when each of the above- 
mentioned Java-AP software is activated will be explained. 

(3-2-1) Operation of Non-Trusted Java-AP Software 

[00143] The operation of mobile unit 16, when non-trusted Java-AP software 
(including both the first non-trusted Java-AP software (tsume-shogi) and the 
second non-trusted Java-AP software (horoscope)) installed in mobile unit 16 by 
the above-mentioned installation operation is activated in mobile unit 16 in which 
JAM is achieved, and the functions corresponding to the software (hereinafter, 
referred to as non-trusted Java-AP) are achieved in mobile unit 16 will be 
explained. 

[00144] When API, which non-trusted Java-AP is about to use is non-trusted 
API, the use of API in this case is approved by JAM since non-trusted API is 
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allowed to use any Java-AP as mentioned above. Hence, non-trusted Java-AP can 
use non-trusted API. 

[00145] On the other hand, when API, which non-trusted Java-AP is about to 
use is trusted API, JAM checks whether SDF corresponding to the Java-AP is 
stored in fixed memory 16D. At this stage, since such SDF is not stored in fixed 
memory 16D, JAM forbids the use of the API by the non-trusted Java-AP. Hence, 
non-trusted first Java-AP will not be able to use trusted API. 

(3-2-2) Operation of Trusted Java-AP Software 

[00146] The operation of mobile unit 16 when the installed trusted Java-AP 
software (telephone directory viewer) is activated in mobile unit 16 in which JAM 
is achieved, and the functions corresponding to the software are achieved in 
mobile unit 16, will be explained. 

[00147] When API, which trusted Java-AP is about to use is non-trusted API, 
the use of the API obviously is approved by JAM as mentioned above. Therefore, 
trusted Java-AP can use non-trusted API. 

[00148] When the API which trusted Java-AP is about to use is trusted API, the 
use of the API can be approved by JAM since SDF corresponding to the Java-AP 
is stored in fixed memory 16D but the operation of trusted Java-AP depends upon 
policy information in SDF. Hereinafter, the operation is explained for each API to 
be used. 

(3-2-2-1) getPhoneList() 

[00149] Since "getPhoneList()" is trusted API, whether the API can be used is 
determined by JAM on the basis of policy information in SDF 204 stored in fixed 
memory 16D. The content of the policy information is the content shown in 
Fig. 4; therefore, the use of "getPhoneList()" is approved by JAM. Hence, trusted 
Java-AP (telephone directory viewer) can use "getPhoneList()'\ In other words, 
trusted Java-AP can read out telephone number directory data. 

(3-2-2-2) getCallHistoryO 

[00150] Since "getCallHistoryO" is trusted API, whether the API can be used is 
determined by JAM on the basis of policy information in SDF 204. Since the 
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content of the policy information is the content shown in Fig. 4, the use of 
"getCallHistoryO" is forbidden by JAM. Hence, trusted Java-AP (telephone 
directory viewer) cannot use "getCallHitoryO". In other words, trusted Java-AP 
cannot read out history data of transmission and reception. 

(3-3) Operation of Renewing Expiration Date of Trusted Java-AP software 
[00151] Next, an example of the operation for renewing the expiration date of 
trusted Java-AP software is explained. In the explanation below, in Fig. 9, 
SDF 204 has been replaced by SDF 204a. However, the file is renewed only in 
that the expiration date is changed from "10:00 AM October 1, 2002" to "10:00 
AM January 1, 2003", but the storage location, the file names, the secret keys used 
as signatures for SDF 204 and SDF 204a are not changed. 

[00152] Mobile unit 16 constantly monitors the present date and hour clocked 
by timer unit 16H and a plurality of expiration dates contained in each SDF 
obtained so far, and determines whether the expiration date is reached. At this 
stage, when the present date and hour clocked by timer unit 16H becomes 10:00 
AM of October 1, 2002, the expiration date of trusted Java-AP software (telephone 
directory viewer) corresponding to APID "0001" is reached, and the operation 
shown in Fig. 20 begins as a result. 

[00153] First, mobile unit 16, as shown in Fig. 21, displays a message on 
displaying unit 1 6c to ask the user whether to renew the expiration date since 
expiration date is reached along with the name of trusted Java-AP software 
"telephone directory viewer" whose expiration date is reached, and waits until the 
user operates. 

[00154] At this stage, when the user carries out the operation to renew the 
expiration date, mobile unit 16 interprets the content of the command, and 
produces request message tm 41 as a parameter of GET Method containing SDF- 
URL (http://www.aaa.co.jp/viewer.sdf) contained in ADF which contains APID 
"0001." Request message tm 41 is transmitted from mobile unit 16,and is 
received by administering server unit 18. 
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[00155] In administering server unit 18, response message tm 42 containing 
SDF 204a corresponding to the content of request message tm 41 is produced. 
Response message tm 42 is transmitted from administering server unit 18, and is 
received by mobile unit 16. 

[00156] On the other hand, mobile unit 16 determines whether SDF 204a is 
obtained by using the above-mentioned SDF-URL. At this stage, the process 
proceeds to the next stage since the success in obtaining SDF 204a is assumed. 
Then mobile unit 16 inspects (decrypts) the signature of SDF 204a by using the 
public key contained in ADF 205, which has already been obtained, and 
determines the authenticity of SDF 204a. When the authenticity is confirmed 
(Step S 35; Yes), mobile unit 16 compares APID extracted from SDF 204a with 
APID contained in ADF 205, which has already been obtained, and determines 
whether the APIDs match. 

[00157] At this stage, the APIDs should match; hence, mobile unit 16 writes 
SDF 204a over SDF 203 stored in fixed memory 16D, and the expiration date of 
trusted Java-AP software (telephone directory viewer) "10:00 AM 
October 1, 2002" is replaced by "10:00 AM January 1, 2003" in this manner. 
[00158] In the instance when the expiration date is determined not to be 
renewed by the operation of the user; when SDF cannot be obtained; or SDF is 
determined to be not authentic; and when APID of SDF and APID of ADF do not 
match, JAM notifies to the user that the expiration date is not renewed, and returns 
the status of mobile unit 16 to that which existed before SDF 203a is obtained. 

(3-4) Operation of Trusted Java-AP Software after Change 
[00159] Next, the operation of the present system after IP, which administers 
IP server unit 13 and IP server unit 14 changes the transmission mode or the 
content of trusted Java-AP software will be explained. However, the present 
change includes the change of the content of Jar file 206 for the purpose such as 
the improvement of trusted Java-AP software, and the change of the transmission 
mode for the purpose such as alleviating the burden on IP server unit 13. To 
achieve the latter change, IP which administers IP server unit 13 and IP server 
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unit 14, as shown in Fig. 22, stores Jar file 206 after the change (hereinafter, 
referred to as Jar file 215) in fixed memory 14A of IP server unit 14, and produces 
ADF 216 by changing the content of ADF 205 in accordance with Jar file 215. 
The above-mentioned operation is required for transmission of trusted Java-AP 
software after the change, and no operation is required for the communication 
provider, which administers administering server unit 18. In other words, the 
communication provider does not need to change list file 200 or SDF 204. 
[00160] The installation operation of trusted Java-AP software after such 
changes is shown in Fig. 23. The operation shown in Fig. 23 begins to differ from 
the operation shown in Fig. 19 when mobile unit 16 requests the Jar file. In both 
figures, response message tm 47 corresponds to response message tm 37, response 
message tm 48 corresponds to response message tm 38, and response message 
tm 49 corresponds to response message tm 39. 

[00161] In other words, the operation of Fib. 23 differs from that of Fig. 19 only 
in that ADF 216 and Jar file 215 are the objects of the process; request message 
tm 48 requesting transmission of Jar file 215 identified by package URL contained 
in ADF 216 ("http://www.sub.bbb. co.jp/viewer.jar") is produced in mobile 
unit 16; request message tm 48 is transmitted by mobile unit 16, and received by 
IP server unit 14; response message tm 49 containing Jar file 215 is produced in IP 
server unit 14; and response message tm 49 is transmitted by IP server unit 14, and 
is received by mobile unit 16. 

[00162] As explained above, in mobile unit 16, the operation in accordance 
with the content of policy information contained in the downloaded SDF is 
approved by trusted Java-AP software corresponding to SDF, and the operation, 
which is not contained in the content of policy information, is not approved. Since 
policy information is transmitted from administering server unit 1 8 to mobile 
unit 16 with the security assured, policy information cannot be falsified by a third 
person, and the trustworthiness of trusted Java-AP is assured in this manner. Also, 
from the user' s perspective, the convenience of the operation improves 
significantly since the above-mentioned trusted Java-AP with a greater freedom of 
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operation approved becomes available, in addition to conventional non-trusted 
Java-AP. 

[00163] In the above-mentioned transmission system, each file is transmitted to 
mobile unit 16 in the order of ADF, SDF, and the Jar file. Transmitting the files in 
this order produces the effects explained below. 

[00164] As already explained, Java-AP software (ADF and the Jar file) is 
designed and produced by IP, and becomes available to general users at exclusive 
sites each IP opens on the Internet (IP server units 12-14 in Fig. 1). Hence, the 
user first accesses the exclusive site of IP, and usually determines whether to 
download the software by referring to explanatory pages of several Java-AP 
software. Then, when the user determines to download Java-AP software, the user 
needs to carry out the operation to command the downloading process. To support 
this process, URL of the file, which should be downloaded next is usually 
contained in the above-mentioned explanatory page for the purpose of 
downloading by anchor tag. At this stage, from the IP's perspective, inserting 
URL of ADF into the explanatory page is most efficient because IP constantly 
keeps track of the URL of ADF since ADF is administered by IP. On the other 
hand, if URL of SDF is to be inserted into the explanatory page, IP constantly has 
to confirm the authenticity of URL by inquiring the communication provider and 
so forth. Therefore, transmitting in the order of ADF, SDF, and the jar file is quite 
meaningful. 

[00165] Also, the above-mentioned order is advantageous when the process for 
version upgrade of Java-AP software, which is carried out in i-mode (trademark 
registered) of NTT DoCoMo is taken into account. In the current service 
specification of i-mode, when a user carries out the operation to request version 
upgrade, the mobile unit first refers to the content written in ADF, and obtains the 
Jar file after version upgrade on the basis of package URL written in ADF. In 
other words, during version upgrade, ADF is first referred to, and the process of 
downloading is carried out thereafter. Taking the above-mentioned fact into 
account, even during version upgrading of the transmission system of the present 
invention, the current service specification does not need to be changed much by 
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initiating the whole process by referring to ADF, obtaining SDF on the basis of 
SDF-URL written in ADF, and obtaining the Jar file; since the process thereafter 
can be carried out in the same flow as that of the ordinary downloading process of 
SDF followed by the Jar file. On the other hand, if downloading of each file is 
defined by the order of SDF, ADF and the Jar file when version upgrade is 
attempted, the process of obtaining the Jar file is carried out without obtaining 
SDF if the downloading process is initiated by referring to ADF. Inconvenience 
can occur to security without SDF since SDF can be rewritten during version 
upgrading. Even from the above perspectives, transmitting each file in the order 
of ADF, SDF and the Jar file is meaningful. 

(3) Modification 

[00166] The present invention is not limited to the above-mentioned 
embodiment, and several modifications such as the ones described below are 
possible. 

[00167] In the above-mentioned transmission system, the mobile unit confirms 
the authenticity of correspondence between the producer of SDF and that of ADF 
by using signature data by the secret key and the public key. In actuality, 
however, transmission need not be limited to the above-mentioned transmission 
method as long as the method used can confirm the authenticity of correspondence 
between the producer of SDF and that of ADF. 

[00168] Also, depending upon the security level required for the system, the 
number of processes in the mobile unit and the IP server unit, or the amount of 
communication among the mobile unit, the administering server unit and the IP 
server unit can be alleviated by the mode which does not contain the public key in 
SDF; does not sign ADF by using the secret key in the IP server unit; and omits 
the confirmation process of the signature in the mobile unit. 
[00169] Also, in the above-mentioned transmission system, the hash value of 
the Jar file is included in ADF corresponding to the Jar file; and the hash value of 
the Jar file is produced in the mobile unit; then the authenticity of the 
correspondence of the Jar file and ADF is confirmed by comparing the hash value 
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in ADF to the produced hash value. However, any method can be used without 
limiting to the above-mentioned method as long as the method can confirm the 
authenticity of correspondence between the Jar file and ADF. 
[00170] Also, depending upon the security level required for the system, the 
number of processes in the mobile unit and the IP server unit, and the amount of 
communication between the mobile unit and the IP server unit can be alleviated by 
omitting the confirmation process of including the hash value in ADF. 
[00171] Also, in the above-mentioned transmission system, whether the 
correspondence of SDF with ADF (and the Jar file) is authentic is determined by 
using the inherent APID to trusted Java-AP, but authenticity of the correspondence 
of SDF with ADF (and the Jar file) can be determined by using the CID inherent 
to the information provider, which provides trusted Java-AP. Also, depending 
upon the security level required for the system, the determination made on the 
basis of APID and CID can be omitted. 

[00172] Also, in the above-mentioned transmission system, the server is 
specified by using the domain name, but the server can also be specified by using 
the IP address. 

[00173] Also, in the mobile unit, by comparing the domain name in SDF-URL 
contained in ADF to a preset letter string, SDF can be determined to be authentic 
only when the domain name is that of a server unit administered by a trustworthy 
organization. In this case, when the domain name differs from the preset letter 
string, mobile unit 16 displays a message that acquisition of SDF has failed, and 
finishes the process without requesting administering server unit 18 for SDF. 
[00174] Also, in this mode, the letter string to be compared (for example, the 
letter string showing the domain name of the communication provider) is pre- 
stored in ROM or the fixed memory of the mobile unit. In the mode of pre-storing 
in ROM, higher security can be assured since the letter string cannot be rewritten. 
Also, in the mode of pre-storing in the fixed memory, trustworthy organizations 
can be stored after the purchase of the mobile unit; therefore, excellent 
convenience can be provided to a user and a trustworthy organization. 
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[00175] Also, in the above-mentioned transmission system, a high level of 
security is assured with a communication provider, which provides the 
communication path used for transmission of SDF as a trustworthy organization, 
but the technologicial scope of the present invention includes the mode in which 
the communication path is not provided by a trustworthy organization. For 
example, by connecting a trustworthy organization to a mobile unit by using an 
encrypted communication path, the trustworthy organization can transmit SDF via 
the encrypted communication path. Also, even if the security of the 
communication path is not assured, by transmitting after encrypting SDF, and 
decoding SDF in the mobile unit, SDF can be transmitted with a certain degree of 
security. 

[00176] In the above-mentioned transmission system, a file is transmitted and 
received in accordance with HTTP, but the system can be modified to assure 
higher security by using HTTPS. 

[00177] Also, in the above-mentioned transmission system, a trustworthy 
organization can be an IP, in other words, the administering unit could comprise 
an IP server unit. 

[00178] Moreover, in the above-mentioned transmission system, API is the 
object for restricting the use by Java-AP, but the present invention is not limited to 
the above-mentioned description, and any resource can be the object. The 
resource can be a hardware resource. Also, the resource can be a network 
resource, or a software resource (explained later). A hardware resource can be a 
resource such as a memory, a speaker, a microphone, an infrared controller, LED 
(Light Emitting Diode) which a mobile unit can be equipped with, or an external 
hardware box such as UIM (User Identity Module) or SIM (Subscriber Identity 
Module) which functions with the mobile unit. 

[00179] Next, a network resource is explained. As mentioned above, the 
mobile unit performs radio communication with the mobile communication 
network. During radio communication, the mobile unit uses a radio resource such 
as a radio channel provided by the mobile communication network. The radio 
resource is one of network resources. Also, the mobile unit, in a higher 
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communication protocol layer than the communication protocol layer the radio 
resource belongs to, uses a communication resource such as a transmission path of 
packets or a communication path of the connecting network. The communication 
resources such as these are included as a network resource. 
[00180] Next, a software resource is explained. A software resource can be 
API, a class, a package and so forth. Various functions are provided by a software 
resource, but a typical function can be a computation process such as encryption 
computation, or a function of transmitting or receiving data with other applications 
such as a Web browser. Also, the technological scope of the present invention 
includes the mode of restricting the use of a software resource, which the above- 
mentioned external hardware box is equipped with. 

[00181] Incidentally, the use of a hardware resource or a network resource by 
Java-AP generally takes place by using a software resource. A mobile unit of the 
above-mentioned transmission system is also equipped with a software resource to 
use a hardware resource or a network resource, and by restricting the use of a 
software resource of this type; the use of a hardware resource or a network 
resource is indirectly restricted. By indirectly restricting in this manner, and by 
preparing various software resources, restrictions which cannot be achieved unless 
restriction on a plurality of resources are changed in detail, such as giving the right 
to change the authorization of Java-AP of the mobile unit or others to only trusted 
Java-AP among all Java-APs, lifting the restriction on allowing to communicate 
only with a server unit accessed for downloading, or allowing to access a specific 
memory domain of the memory can easily be specified. Also, the mode of 
indirectly restricting the use of a software resource of the above-mentioned 
external hardware box by restricting the use of a software resource installed inside 
the mobile unit is included in the technological scope of the present invention. 
[00182] With regard to a method of expressing permission, a flag 
(permit/forbid) corresponding to one resource can be used, or permissions of a 
plurality of resources can be denoted by one piece of information. 
[00183] Also, in the present invention, the types of permission can be denoted 
to permit (or forbid) the use of a resource with a plurality of types. In this case, in 
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the mobile unit, a more precise control can be achieved. For example, since 
modes of both reading out and writing in (types of use) exist in the memory, the 
memory can be used for both reading out and writing in by trusted Java-AP 
although the memory is used only for reading out by non-trusted Java-AP. Also, 
for example, when the Web browser and so forth are activated while Java-AP with 
the right to use a packet transmission path is activated in a mobile unit in which a 
plurality of applications can share one packet transmission path, control can be 
such that Java-AP which is permitted to "exclusively use a packet transmission 
path" can exclusively use a packet transmission path although the Java-AP which 
is not permitted to "exclusively use a packet transmission path" cannot exclude the 
sharing of packet transmission path by a Web browser and so forth. 
[00184] Also, by further modifying the above-mentioned example, the 
following control can be possible. In other words, Java-AP with a certain type of 
permission can exclusively use the packet communication path without the user's 
consent. Also, Java-AP with another permission can use the packet 
communication path without the user's consent, but needs to obtain the user's 
consent to exclusively use the packet communication path. Also, Java-AP with 
another permission can use the packet communication path without the user's 
consent, but cannot exclusively use the packet communication path. Also, Java- 
AP with another permission can use the packet communication path only with the 
user's permission. Also, Java-AP with another permission cannot even use the 
packet communication path. As it is obvious from these examples, "types of use" 
of the present invention also contain types of a process when a resource is used (a 
process of obtaining the user's consent/ a process of not obtaining the user's 
consent) 

[00185] Also, in the above-mentioned transmission system, an identical list 
page is provided for all mobile units, but a different list page can be provided for 
each mobile unit. 

[00186] Also, in the above-mentioned transmission system, the operation of 
Java-AP is restricted when the Java-AP is executed. Instead, by including policy 
information in the Jar file stored in the IP server unit, and when the Jar file is 
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downloaded in the mobile unit, activation of the Java-AP corresponding to the Jar 
file, or installation of Java-AP software containing the Jar file can be forbidden if 
comparison between the policy information and the policy information in SDF 
results in a mismatch. Only the permission given to the item as a result of the 
match in policy information can be valid. 

[00187] The public key of the communication provider is provided to mobile 
unit 16 from IP server units 12-14 by being contained in ADF. However, instead 
of limiting the provision of public key as described, the public key can be pre- 
stored in the mobile unit. With regard to methods of pre- storing the public key in 
the mobile unit, methods such as transmitting through communication and by pre- 
storing in the fixed memory, or selling the mobile unit after writing the public key 
into ROM, are possible. 

[00188] Also, in the above-mentioned transmission system, software is 
delivered to a mobile unit, but the technological scope of the present invention 
includes the mode of transmitting software to a terminal unit besides a mobile unit. 
[00189] In the above-mentioned transmission system, when the expiration date 
of trusted Java-AP software is reached, the process for renewing its expiration date 
begins. However, instead of limiting the timing of renewal to the above- 
mentioned one, various modes such as arbitrary timing as the user wishes, or 
periodical timing such as once at the end of each month can be adopted. 
[00190] Also, with regard to the method of setting the expiration date, the 
expiration date can be set in accordance with the date as already explained, and for 
example, by the period after trusted Java-AP software is downloaded (for 
example, when trusted Java-AP is available only for a month after its installation), 
or the expiration date can be set by the number of times of execution, or the period 
of execution of trusted Java-AP software. In other words, the expiration date can 
be any information as long as the upper threshold is set so as not to allow Java-AP 
software to be limitlessly executed. 

[00191] For example, when the expiration date is set by the number of times 
execution is carried out, the necessary information can be drawn from JAM, which 
refers to policy information in SDF each time trusted Java-AP software is 
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activated, and the same number of references carried out by JAM can be counted 
as the number of times execution of trusted Java-AP software is carried out. 
When the counted number of times of execution reaches the pre-determined 
number, the renewal process can be initiated. 

[00192] Also, when the means of accumulating and counting the period when 
trusted Java-AP software is executed (for example, the means such as writing in 
the trusted Java-AP software as a subroutine) is equipped, counting is possible 
even when the expiration date is set by the period of execution. Then, when the 
period of execution counted reaches the pre-determined time, the renewal process 
can be initiated. 

[00193] In the explanation of the above-mentioned transmission system, the 
expression "the expiration date of trusted Java-AP software" is used, but more 
precisely, the expiration date can be that of the Jar file itself, or even that of both. 
[00194] Also, in the above-mentioned transmission system, execution of 
trusted Java-AP software whose expiration date is reached is forbidden when the 
expiration date is reached but cannot be renewed. However, trusted Java-AP 
software can be changed to non-trusted Java-AP software when its expiration date 
is reached, instead of limiting in the manner as described above. In other words, 
Java-AP software whose expiration date is reached is regarded as non-trusted 
Java-AP software, and is subject to greater restriction as non-trusted Java-AP 
software after the change. 

[00195] Also, the above-mentioned embodiment can be modified so as to let 
SDF of any trusted Java-AP software expire. 

[00196] In the example of the modification, the administering server unit is 
equipped with the memory unit to store SDF of several kinds of Java-AP software 
as in the above-mentioned embodiment. When the controller of the administering 
server unit receives each SDF from the communication unit, or when the 
controller receives SDF stored in the memory medium, the controller stores SDF 
in the memory unit. 

[00197] Also, to the administering server unit, the command to void the SDF 
for any trusted Java-AP software can be inputted. The command contains APID 
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of the trusted Java-AP software to which SDF to be voided corresponds. The 
command as such is inputted to the inputting unit of the administering server unit 
by the operator; or the command is transmitted to the administering server unit 
from the relevant IP server unit via the network, and is received by the reception 
unit of the administering server unit. When the controller of the administering 
server unit receives the command via the inputting unit or the communication unit, 
the controller stores information showing that SDF identified by APID in the 
command is voided in the memory unit. As a result, in the administering server 
unit, the disclosure of SDF discontinues, and downloading of the Java-AP 
software using SDF becomes impossible. 

[00198] A case such as when SDF of certain trusted Java-AP software is 
transmitted to a certain terminal unit, and SDF is voided thereafter could be also 
possible. In such a case, SDF which has already been transmitted should be 
voided so as not to function as SDF. For this purpose, the following method can 
be used. In other words, the terminal unit inquires the administering server unit 
about the validity of SDF in a constant period of time, and when the response 
showing that SDF is voided returns from the administering server unit, the 
terminal unit forbids the use of SDF thereafter. At this stage, shortening of the 
time period for inquiry is effective in decreasing the number of times execution of 
trusted Java-AP software is carried out after SDF is voided. However, if such a 
method is adopted by each terminal unit independently, the traffic becomes 
enormous, and the communication fee the user must pay also becomes high. On 
the other hand, among the users of terminal units, some users frequently command 
the execution of trusted Java-AP whereas some users command the execution of 
trusted Java-AP software only at times; hence, increasing the traffic and the 
communication fee for the latter people is not wise. 

[00199] To solve the above-mentioned problem, a process is carried out in the 
present embodiment as follows. First, the administering server unit includes 
frequency data N and period data T when administering server unit transmits SDF 
from the communication unit to a terminal unit. At this stage, frequency data N is 
the data to command transmission of inquiry about the validity of SDF whenever 
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the number of times execution of trusted Java-AP software is carried out exceeds 
the integral multiple of N. Also, period data T is the data to command 
transmission of inquiry about the validity of SDF when time T passes after the 
execution of trusted Java-AP software, and before the execution of Java-AP 
software is next initiated. 

[00200] When the terminal unit receives certain SDF, the terminal unit 
transmits to the administering server unit the inquiry about the validity of SDF in 
accordance with frequency data N and period data T in SDF. The configuration of 
the controller for carrying out the process for certain SDF is shown in Fig. 24. 
When a plurality of SDFs are stored in the terminal unit, controllers shown in 
Fig. 24 are equipped for the same number of SDFs. The elements denoted by 
codes 501-504 in Fig. 24 show the circuit comprising the controller, or the routine 
executed by the controller. 

[00201] First, when the controller of the terminal unit receives SDF, the 
controller activates the circuit shown in Fig. 24 or the routine for SDF. Then the 
controller extracts frequency data N and period data T from SDF. Then frequency 
data N is given to divider 502, and period data T is given to timer 503. 
[00202] Counter 501 adds the counted number by one whenever trusted Java- 
AP software corresponding to SDF is activated. Divider 502 divides the counted 
number from counter 501 (in other words, the number of times, activation of 
trusted Java-AP software is carried out) by frequent data N, and outputs signal "1" 
when the remainder as a result of the division becomes one. 

[00203] Timer 503 specifically is a decrementing counter. When trusted Java- 
AP software is activated, period data T is written into timer 503 as the initial value 
of the counted value. Hereinafter, timer 503 proceeds with decrementing count by 
being synchronized with the clock of the specific frequency. Then, when the 
period of time T is counted down, timer 503 outputs signal "1." When trusted 
Java-AP software is reactivated before the period of time T is counted down, 
period data T is set to timer 503, and the new decrementing count begins from that 
time on. 
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[00204] OR gate 504, when signal "1" is outputted from divider 502 or 
timer 503, generates a signal to command inquiry about the validity of SDF. 
[00205] Fig. 25 is a time-chart showing the above-mentioned operation. As 
shown in the figure, OR gate 504 generates a signal to command inquiry about the 
validity of SDF such as N + the first time, 2N + the first time with frequency data 
N given. The controller, when the signal is generated, transmits to the 
administering server unit inquiry about the validity of SDF by the communication 
unit. The inquiry contains APID to identify SDF, which is the object. When the 
controller of the administering server unit receives the inquiry from the 
communication unit, checks whether SDF identified by APID being inquired is 
valid by referring to the memory unit, and returns the outcome to the terminal unit 
by the communication unit. When the controller of the terminal unit receives from 
communication unit, a response that inquired SDF has expired, the controller 
carries out the operation so as not to allow Java-AP software corresponding to 
SDF to be activated. 

[00206] Also, in the example shown in Fig. 25, a signal to command inquiry 
about the validity of SDF is generated since the time elapsed has exceeded T after 
the second time of execution of trusted Java-AP software before the third time of 
execution. Even in this case, the same inquiry, the response from the 
administering server unit, and the operation of the terminal unit in accordance with 
the response as the above-mentioned ones is carried out. 

[00207] Some of the advantages of the above-mentioned modification are as 
follows. 

[00208] First, if one uses trusted Java-AP software frequently, inquiry is not 
carried out when operation of inquiry generation is performed on the basis of 
period data T since trusted Java-AP software is always activated before time T is 
counted down. Hence, the method of inquiring when the number of times 
activation is carried out exceeds N is effective. 

[00209] On the other hand, if one only uses trusted Java-AP software 
occasionally, timely voiding of SDF is impossible since the number of times 
activation is carried out does not often exceed N. Hence, for such users, the 
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method of inquiring when the time elapsed after the activation exceeds T is 
effective. 

[00210] The present modification is effective for both types of users since 
methods are used parallel to each other. 



